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1.0 INTRODUCTION 



1.1 MOTIVATION 



1.2 GOALS 

This standard is intended to (1) furnish a design for labelled files 
that will allow the users to write files on one system that supports 
cassettes, and read them on another, (2) provide a consistent growth 
pattern for support of cassettes, through a system of levels of 
support, (3) allow the fewest number of data formats consistent with 
the needs of computers with different word lengths, and (4) provide a 
standard for unlabelled files. 



This standard applie 
labelled cassette f 
Digital cassette: 

CAPS-8 

CAPS-ll/CAPS-11 BASIC 
DOS-11 



Cassette hardware is not required 
beginning of the tape. Future casse 
not prohibit software from writing at 
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1.4 HISTORY 



One previous 




standardizing file formats. It 


allowed for : 


several items that h 


iave been deleted from the current 




iable-length records. 


an optional second header record, 




extra data formats 


Variable length records were 


eliminated, b 


ecause they are hard 


1 to implement. The supplementary 






jse the size of the medium seemed tc 


make a second header a candidate 




data formats 


because we decided on 




formats. 







1.4.2 Change To Previous Standard Proposal 

The codes for the binary data formats were redefined, because the 
previous standard did not adequately spell out how the codes were to 
be used, and confusion resulted. Thus, code zero and codes in the 
range 2 to 14 (used by the previous standard proposal) are now listed 

conversion, a system encountering cassettes with a code in that range 
should assume correct type and continue. Example: A DOS-11 Linker 
would ordinarily expect data type 22. If it encounters data type 3, 



The D 


revious 


effort was not 


rigor 


ous 


in 




s d 


efiniti 


on of 


level: 








nd the 






■al 


opt 


ions beyond that. ] 




:he prim* 






the 






ty of l 








interchange medium, we 


decide 














which 




for cassettes 


could 


be 






sed. 












mber and defini 








-ly 


unused 










served for (1) 


future 




srd 




•, and 


(2) us 




Cassette labels (as opposed 


to 


file 


1; 


abels) 


were conside 


red ar 
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All lev€ 


Is are nested 




f the opera 


.ing system 


clain 


s level n 








t supports a 


11 features 


of 1 




levels 


zero through 


n-1 . Tr 




is necessary 


that all 


level-ze 


ro reading programs be a 




level zero 


forma 


. and that 


all lev 


al-zero writin 


3 programs 


shall writ 


e only lev 


el-zer 






, that all 1 




reading pr 




able 








ne formats 


and that al 




prog 






lv level-one f 


ormat incl 


uding at least one lev 


el-ze 


o format. 


Further 


.hat all leve 


1-two read 


ing programs 


be able tc 




level-two 








level-zero 




All 


level-zero 








of level-on 




All 


level-one 


formats 






of level-tv 


ro formats. 










supports DEC cassette 




the 


bility to 




rite and zer 






ng type 1 


ASC 


I files. 


Therefo 


e, level zero. 


is the on 


ly guarantee 


d interchange level. 



1.5 RELATED STANDARDS ACTIVITIES 

ANSI and ISO have recently formed c 
may generate standards which may 
revisions of this standard. 



1.6 FUTURE STANDARDS ACTIVITIES 



standard 
defined 


ASCII 


that ASCII 
and Binary 


formats. 


y dc 


n ta a r 


formats 
new for 
Software 


s wishin 


3 to define new data 
der becomes compatibi 
required, the proper 
ring Standards Commit 


form 

lity 

pr 


If it 
Dcedure 


2.0 TERMINOLOGY 










A CASSETTE consi 

be preceded by a 
gap and a SENTTN 


single FILE GAP. Th 

file gap*; the last 

EL FILE (see Section 


first file 
file must 
3.2), or by 


block o 


a file 


ts of a seq 
, separated 
is called th 


jence of 
e file he 


a fi 
ader 


er by b 

block. 



A block consists of a sequence of 1 to 2**16 - 1 DATA BYTES followed 
by a 2-byte CYCLIC REDUNDANCY CHECK. (This is a logical limit, there 
is no physical limit, except for the length of the tape.) 



A CHARACTER is a byte interpreted via the ASCII character codes. 
Parity is not required. The high order bit (bit 7, the leftmost bit) 
of each eight bit byte containing an ASCII character should be masked 
on reading. Parity is checked by the software only, not by the 

isigned to a file at creation, to 
5 version of the same file. 

Blank The ASCII character 'space', whose value is 040 (octal). 

Null The ASCII character whose value is 000 (octal) . 

Zero Byte A byte all of whose bits are zeroes. 

A File Key is defined as n number of characters of file name and m 
number of characters of file name extension (see Section 3.0 for 
definition of File Key for each level) . 

40 (octal). The first character must not be blank; there shall be no 

padded on the right with blanks. For level two, bytes 0-5 and 2fi-28 
are considered as a unit, when applying these rules. For levels zero 
and one, bytes 26-28 are undefined. 

: ASCII, bit 8 is undefined and 



ath nulls follov 



CTRL/Z (032(8)) and all data follov 



labelled standard: 



3.0 THE STANDARD - LEVELS 

LEVEL ZERO: 

Level Zero must support: 

1. 32 (decimal) -byte header block, which 

six-character name of file 
three-character file name extensio 
date 



Logical end-of-file 
Logical end-of-tape 
Fixed-length, 128 (decin 
ASCII data (type 1) 









LEVEL ONE: 

Level One must support: 

1. All attributes of leve 

2. Read/write support for 

3. File Key is defined , 
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ributes of level : 



5-bit binary generatic 



Fixed-length blocks of fron 



!.l THE FILE HEADER BLOCK 



The File Name 



software/hardware systen 



» file key (for a given lei 
intended for interchange. I 
a this, the user mam 

is intended for interchange. 



changing the name 


to 


*EM 


TY. To chec 


for a deleted file. 






only the firs 


character. This i 






low for futur 


means for deleting 


a f 


le 


e.g., *BAD) . 
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3.1.2 The Dati Type 

Ability to read and write ASCII data (type 1) is required for 
zero. Any system may support any other data type, regardles 
level, however these data types are not required to be supporte( 

Byte 9 in the file header block con 
Type defines the way in which data 
3-1 lists the Type Codes and gives the meaning associated with each. 

The goal is to have the minimum number of types consistent with 
Odd numbered types are reserved 
it to show the presence of ASCII 
data. 

Type zero (undefined) is required, because files on OS-8 and RT-11 
disks do not carry data type information, but file transfers between 
disks and cassettes should not be prohibited for that reason. Hence, 
for example, the OS-8 MCPIP program will transfer disk files to 
cassette and give a zero type, unless the user specifies type. 
Paragraph 1.3.2 describes the reasons for omitting definitions for 
types 2 through 14. 

For further explanation of the various definitions of these data 
types, see Appendix A. 
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Table 3-1 Standard Data Types 

Description 

5 of this type 
can be restored to a 



Cassette ASCII. 

Unknown data type. To copy a file of this type 
to another medium, copy all 8 bits per byte and 
store in a format that can be restored to a 
cassette. (These codes must not be used by any 
new software.) See Appendix C for explanation 
of the use of these codes in old software 



line nurr 



PDP-8 Cassette bin-loader 
the CAPS-8 User Manual, 
may use this type code. 



PDP-11 OBJ format. Not to be used for othei 

PDP-11 LDA format. See comments on Type 20. 

Reserved for future use of PDP-10. 

PDP-11 TSK format defined in RSX-11M Tasl 









Builder Manual. 




30 






Bootstrap File for PDP-8 




32 






Bootstrap File for PDP-1 




34-50 






Reserved for bootstraps. 




^ey^ust^r 


ig mi 


zTrT' 


, all proqrams must set t 
(*) if type is unknown. 


:he type byte correct 

Proqrams readinq fi 

h the expected type 



3.1.3 File Block Length 

Bytes 10 tnd 11 of the File Header 
(non-header) block up to the nex 
requires 128 here; level two files 



ist significant 
length equals 
byte \3 
of byte 11. 



File Sequence Number 



Level two files a two. The high-order four bit; 
served for the possibility of continuation he; 
Dgrams must ignore the high-order four bits \ 
ber. This is reserved for future standards use. 



3.1.6 File Creation Date 

This field is required for 
contained in the six charact 
this date shall consist of 
day number (01-31), the mon' 

first byte will be zero (nul 
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3.1.7 Generation Number 



Byte 20 contains an 8-bit binary generation number for all levels. It 
must be zero if the generation number is unknown or not supported (as 
in CAPS-11 or DOS/BATCH-1 1 ) . Level two files have a 16-bit generation 
number, with high-order bits in byte 20. Byte 21 must be zero for 



3.1.8 Record Attributes 






Byte 22 specifies certain 
two files. Bit refe 


characterist 
e printer, te 


ics for data recorded on level 
:ting of records destined for 
■rminal, etc. The definition of 


Bit - If 1, indict 


ites that whe 
trol characte 


n printing the data, the first 
is to be interpreted as FORTRAM 


Bits 1-7 - Unused; must 


be zero. 




This byte is undefined for 


levels zero 


and one. 



3.1.10 Extended Filename Bytes 

Level two files insert the last three characters of the filename in 
byte 26-28. Contents of these bytes must be 7-bit ASCII characters 
for level two. These bytes are undefined for level zero and level 



3.1.11 User Bytes 
Bytes 29-31 are res 
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3.2 SENTINEL FILE 



Logical End of Tape may be denoted by clear trailer or a 32-byte 
header block with the first byte null. Such a block follows a 
gap and is called a sentinel file. See Section 5.3 for example 
logical End of Tape. 



3.3 BOOTSTRAP FILES 

Bootstrap files must be the first file on the t 

exactly level zero characteristics, i.e., 128-byte 

etc. Data type must show bootstrap type. 



3.4 MULTI-VOLUME FILE 
Level zero systems do r 



3.4.1 READ Support 



volume is incremented by one. If the expected value is not found, 

Level zero systems and other systems reading level zero cassettes 
report end of file when clear trailer or a file gap is reached di 
READ. Level one or two systems reading level one or two casr 
must report end of file only on reaching a file gap. When they 
clear trailer, they must output a message to the operator ; 
whether end of file has been reached. 

The operator must indicate whether more volumes exist. If the 



one, and the next higher volume number (byte 12) . If it finds such a 
the cassette, the s/stem must report same and allow the operator tc 
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3.4.2 WRITE Support 



Level zero systems must give a "device full" message when clear 


trailer 


is reached, and close the file. (This implies that the last 


file on 


i the cassette may be an incomplete one.) Level one and two 


systems 


that reach clear trailer on WRITE must: 


1. 


Insure that the block being written when clear trailer was 




reached will give a clear trailer error when read back. This 




involves first checking the byte transfer count to determine 




if all bytes of the current block were transferred to cassette 




before the clear trailer indication was received. If the 




count indicates that all bytes were not transferred, then this 




partially-written block will always give a clear trailer 




indication when read back with the proper block size. This 




last block must be retained for transfer to the next volume. 




if the operator so specifies. If the byte transfer count 




indicates that all bytes were successfully transferred to 




cassette before the clear trailer indication was received. 




then the system must backspace one block and write a file gap 




over this last block. Writing a file gap if all data bytes 




were transferred insures that this block cannot be read on any 




drive, and thus, the block will not be duplicated if the 




operator chooses to continue the file on another volume. This 




last block must be retained for transfer to the next volume if 




the operator so specifies. 


2. 


Send a message to the operator indicating that physical end of 




tape has been reached and requesting that the operator mount 








the file without mounting a new cassette. (This always 




results in the loss of at least the last block of the file.) 




If the operator wishes to close the file, the system should 




rewind the volume which filled up. It need perform no further 




I/O on this volume; the last file is already effectively 



s which filled i 



After the operator has : 


Loaded the cassette, the system mi 


space to logical end of 


tape, and write a new header wi 


incremented volume numbe 


r. It must then write out the blc 


left over from the prev 


ious volume and continue process ir 


It is recommended that th 


le operator have the further option 


specifying that the newlv 


'-mounted volume be treated as a bl; 


cassette. In this case, 


the system begins writing the hear 
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The multi-volume file write support for 
level one and two systems described above 
is intended only for use with fixed-length 
128 byte blocks. For longer ^lock lengths. 



:ing a 



iing 



'ritt 



e gap a 



; bloc 



:railei 



detected can result in a gap larg* 
to be recognized by hardware as a file qs 
Upon reading this last file on the volun 
such a gap would signify logical end 
file, even though the user may ha 
specified that output be continued or 
another volume. This problem does r 
arise with block lengths of 128 bytes 
less, since overwriting a 128-byte block 
physical end-of-tape with a file gap canr 
result in a gap in a gap large enough to 
recognized by hardware as a true file qap 



4.0 STANDARD FO 
Simple systems ( 



UNLABELLED CASSETTES 1 
!.g., "intelligent" tet 



.entin 



OR INTERCHANGE 
paper tape supp 
1 file, etc. 



The format for an unlabelled cassette is as follows: first, the clear 
leader; next a file gap; then the data, grouped with successive 
fixed-length blocks. These blocks are separated by block gaps and the 
data is terminated by a file gap. Block length and content must be 
agreed upon in advance by systems wishing to interchange unlabelled 

cassettes. (128)10-byte blocks a " " " 

default size. 
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5.0 EXAMPLES 



5.1 HEADER BLOCK FORMAT 









on 


1 Bl^rJmh ' 


1 Sequence Number 1 


1 Support Level 1 


1 Date 1 


1 Generation Number 1 


1 RRC Attributes 1 


1 Undefined for Leve 
1 & 1, must be se 
1 zero b}<_level 


s 1 
2 1 


1 Last 3 characters 
1 File name 
1 Level 2 


of 1 


1 Reserved for 1 
1 Customer 1 



TYPICAL FILE HEADER BLOCK FOR LEVEL ZERO 



I FILNAM I TXT I 1 I 



I Unspecified ! 



> 9 10 11 12 13 



20< >25 2<;<— 



5.3 LOGICAL END OF TAPE 



Date Bloc 



Data Block 



5.4 BEGINNING OF TAPE 



Leader Gap 
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APPENDIX A 



FORMAT OF PDP-8 BOOTSTRAP FILE 

ist be such that when positioned as the first file on a 
, it can be read in by the MI8-EL RON bootstrap loader and 
inched to will perform some bootstrap function (like read in 
md file on the cassette which may be the monitor). 



i ROM bootstrap does 



/CASSETTE SYSTEM BOOTSTRAP 



COPYRIGHT 1972 

DIGITAL EQUIPMENT CORPORATION 

"AYNARD, MASS. 01754 



/STARTING LOCATION (NORMALLY) : 



6700 


KCLR=6700 




KSDR=6701 


6702 


KSEN=6702 


6703 


KSBF=6703 


6704 


KLSA=6704 


6705 


KSAF=6705 




KGOA=6706 


(S707 


KRSB=6707 


7002 


BSW=7002 


3602 


LOC=3602 


4000 


*4000 


1237 STA 


,RT, TAD M50 


1206 CRCCHK, TAD L260 


6704 


KLSA 



04005 


5204 


RDCOD, 


JMP .-1 


04006 




L260, 


CML ST* RAL 


04007 


6702 




KSEN 


04010 


7610 




SKP CLA 


04011 


3211 




DCA 



/PDP-8/E, -8/F, AND -8/M ONLY 
/LOCATION WHERE SECONDARY 
/BOOTSTRAP REALLY GETS LOADED 

/INITIALIZE PULSE CLEARS THE LINK 

/CHANGE READ CRC CODE (6) TO 

/REWIND <1> [SIN] 

/LOAD READ CRC CODE INTO STATUS 

/REGISTER A [JMP I STARTl 

/FIRST TIME THROUGH, LINK MUST 

/BE 1 HERE 

/INITIATE THE OPERATION (READ 

/CRC OR REWIND OR FRWD FILE GAP) 

/READY? 

/NO, WAIT 

/SET L=l AMD AC= A WALT (7776) 

/ANY ERRORS? 

/MO 

/HALT ON ANY ERROR EXCEPT FOR 



mmn 
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3<S3^ DCA I PTR 

1205 TAD RDCOD 

6704 KLSA 

6705 LOOP, KGOA 



/REWIND OR FRWD FILE GAP 

/CAN'T ALLOW 'TAD I PTR" LATER 

/TO AFFECT LINK 

/GET CODE FOR READ (0) 

/LOAD INTO STATUS REGISTER A 

/FIRST TIME STORES 173 INTO MEMORY 

/(8-BIT COMPLIMENT OF RDCOD) 

/OTHER TIMES READS ONF, 6-BIT 

/BYTE OF PAIR 

/NEW DATA WORD READY? 



/NO, 



AIT 



04020 


7002 




RSVJ 




/MOVE 6-BIT BYTE TO H.O. AC 


04021 


7430 




SZL 




/WHICH 6-BIT BYTE OF THE PAIR? 


(34022 


1636 




TAD 


1 PTR 


/2ND. SO ADD IN 1ST BYTE 


04323 


7022 




CML 


HSW 


/SWAP BACK AGAIN. SET LINK TO 
/INDICATE NEXT BYTE 


04024 


3636 




DCA 


I PTR 


/STORE BACK INTO MEMORY 


04025 


7420 




SNL 




/ARE WE DOME LOADING BOTH 6-BIT 


0402fi 


2236 




ISZ 


PTR 


/YES, SO POINT TO NEXT MEMORY WORD 


04027 


2235 




ISZ 


KNT 


/BUMP COUNTER 


04030 


5215 




JMP 


LOOP 


/REITERATE 


04031 


7346 






CLL RTL 




04032 


7002 




BSW 




/SET AC=7577 


04033 


3235 




DCA 


KNT 


/SET COUNT TO ALLOW READING A 
/200 BYTE RECORD 


04034 


5201 






CRCCHK 


/GO CHECK THE CRC 


04035 


7737 




7737 


/ONES COMPLIMENT OF NUMBER OF 












/BYTES TO LOAD 


04036 


3557 


PTR, 




-23 


/MEMORY LOCATION TO BEGIN LOAD AT 


04037 


7730 


M50, 


-50 




/CLA SPA SZL 



/THI? ROUTINE BINARY LOADS BINARY FILES INTO MEMORY. 

/IT BEGINS BY LOADING A RECORD OF SITE 40, 

/THEN CONTINUES TO LOAD SUCCESSIVE RECORDS EACH OF SIZE 

/200. 

/THIS PROCESS CONTINUES UNTIL IT DESTROYS ITSELF. 

/ LOCATIONS 4000 AND 4001 ARE REPLACED RY JMP I(BIN)1 

/BY THE SECONDARY BOOTSTRAP. 

/THE FIRST MEMORY LOCATION BEFORE A NEW CASSETTE RECORD 

/IS READ IN IS LOADED WITH A RANDOM VALUE (173). 

/SUCCESSIVE WORDS ARE LOADED WITH THE 1.2-BIT QUANTITY. 

/100A+B, WHERE A AND B ARE SUCCESSIVE 6-BIT BYTES FROM 

/THE CASSETTE RECORD. 

/MEANINGLESS WORDS GET LOADED IF THE CASSETTE CONTAINS 

/8-BIT BYTES AS CAN (AND DOES) HAPPEN WHEN 'LOADING' 

/THE HEADER, AND WHEN 'LOADING' THE ORIGIN AT THE 

/BEGINNING OF THE RECORD. 



mmm 
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Lcally, the bootstrap file is a standard PDP-8 binary file excer 
: origin settings are treated as data words. The ROM reads dat 
1 successive records (beginning with the header record) and treat 
> data as binary data (two successive bytes form one 12-bit woi 
lg the low order <5-bits of each byte) . These binary data words ai 
■--''■ • • - -- .ssive locations beginning with locatic 

ion was chosen so that the random data i 
there and then the real data from tt 

loading into location 3^02. 



NOTE 



a record gap is encountered, 
core location is loaded with an 
led 12-bit word. Data in the 



until locations 4000 and 4001 are loaded, 
loaded with the starting address of the 
ation 4001 must be loaded with a 5^00. (This 
s of 130) . 



It is strongly recommended that there be only one bootsi 
namely the one used by CAPS-8 called C2R00T. If necess 
read in a tertiary bootstrap to do further loading (se 
program called C3B0OT) . 



A. 2 PDP-8 CASSETTE BINARY FORMAT 

data entry: 2-bytes 

1st byte: bits 8,7 must be 00 

2nd byte: bits 8,7 must be fll 
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5-Jun-75 


«*,. 


bits 8,7 


are high order 


2nd byte: 


bits 8,7 
bits 6-1 


are low order r 


field entry: 


1 byte 






bits 3-1 


must be 11 

is new field se 


trailer entry: 


1 byte 






bits 8-1 


must be 13 000 



These entries may appear in any order except that trailer entries 
only appear at the end of the file and there must be at least one t 
of leader/trailer at the end. If the last entLy before the fi 
trailer is an origin entry then that represents the program's start 



A. 3 PDP-11 CASSETTE FORMATS 

1. Formatted Binary Format 

Records are word aligned, variable length and only the "tex 
section can cross block boundaries. Records are variab 
length and can cross block boundaries. Mulls are used 



Byte 1 001 

Byte 3 low order of (length of "DATA" in bytes) 

Byte 4 high order of (length <jf "DATA" in byte; 
Byte 5 

Byte n (last byte of DATA) 

Byte n+1 Checksum byte = - Byte 



SDIDDSD 



DEC STD 125 



The format for the "data" information will 



PDP-11 OBJ & LDA formats (types 20&22] 

Format, but differ in theii 

interpretation of "DATA". 



2. 11M TSK Format 

Cannot be completely defined here. 

♦Since there will always be an 11M Task Builder 



SDIDDSD 



DEC STD 125 



APPENDIX B 
FORMAT OF CASSETTES FOR F 



copied from one drive to another, there is 
that the physical length of the data on the cony will be t 
the physical length of the original. Although data may fit 
' attempting to copy this data onto another cassett 



•lore specifically, we recommend that a cassette intended for 
interchange should not contain more than 2<S0003 (octal) bytes of data. 
When computing this number, each record gap written should be 
considered to be equivalent to 56 (octal) bytes of data and each file 
gap (including the initial one) should be considered equivalent to 454 



Currently 




i SDC canno 


bigger t 




this. 




of 


multi-voli 


to SDC) . 







miam 



APPENDIX C 
NON-STANDARD FILE TYPES 



Description 
paper tape image 

(wastes low order 4 
core image format #2 
(only the low order 



ire image format 34 
one 35-bit computer <* 
(only the low order c 



image format ffi) , 



mmm 



